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(57) Abstract 

The present invention relates to the replacement of software in an operating 
computer system, and in particular, to the synchronistic of ^ JJ™«f 
oSween processes within the old software to processes ^j^. 80 ^ 
The synchronization of state transfer between processes ^S" *^ 
and tte new software comprises the following steps: prepanng tf* old i sane 
process within the old software for a forthcoming .shutdown^vaMgn forte 
state transfer, preparing the new static process withm the new software to tate 
over, transferring ^ resource objects in the old static process to Ae 
orocess- ordering the old static process to remove all services, teminaong the 
M^c process; and committing the new static process to take ™ ****** 
mat the new static process is the sole owner of all the resource objects previously 
claimed from the old static process. 
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Method of synchronization allo.ina state transfer 

TECHNICAL FXEI* OF THE repla cement of software in 

The present invention relates to the synchro n- 

software to processes within a new software. 

DESCRIPTION OF RELATED »** ba periodically 

^ aspect of computer ^« delerions in order to 

updated with ^^^Tun^onallty to the user, to 
continue to provide ^equate * aiscrepancies 
optimise the software and ~ ^ e-> As new features 

««t arise throughout the «*^ of ^^ „ ^ the old 
are added to software, it :Jm desi ^ ^ ^ ^ 

software with the new versions as earl^ P sofware . 
provide the user with the features of the new 

In certain types of computing -^J^, ZTZ^Z Z 
b atch processing systems, ^"^^"f^er system is 
mother presents few obstacles . ■ ^ ^ is 

merely shut down during a period of day when available . Tne 
ectlvityandthe^te^ Per^-ereadi^ ^ ^ _ 

old software is then simply rem compu i:ing system is 

version of * ^software- There, ^ ^ ^ ^ neM 

restarted and all future a« * courS e assumes that 

version of the software. This debugged on an 

the new software has been adequately tes«d and the 

off-line system to the point ^^^^ ade quately 
operational management are <^^\^^ a Kithou t undue 
.erform the functions ^-starting the 

interruptions that require halting an 
entire computing system. 

such as modern stored 
In other types of computing systems such ^ 

i f<zvr\ telecommunications ^ 

neither the ^J^Z^Va^----- - 

of software in the system worslons of software cannot 

SUBSTITUTE SHEET (RULE 26) 
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processing calls. The software must be tested while in operation 
in order to determine whether the software will adequately 
function under live operating conditions and whether the new 
portions will properly interface with all of the other software 
blocks that form a part of an operational SPC switching system, 
in addition, telecommunications switching systems are virtually 
never out of operation. Ideally, these systems would run 
perpetually, without interruption because of the continuous need 
for communications services within a community. That is, there is 
a continuous flow of telecommunications traffic being processed 
through the system even at off hours of the day or night and any 
interruption in the operation of the switch results in a non 
desired disruption of the telecommunications traffic. Such a 
disruption could be extremely damaging to the system's operation 
and its effectiveness, as well as its acceptance among users or 
costumers of the system. 

These real-time requirements of telecommunications exchange 
systems place severe constraints on both the testing of enhanced 
versions of the software, or portions thereof, containing new or 
improved functionality, as well as the substitution of software 
containing error corrections or "bug fixes" in the switch without 
disrupting existing telecommunications traffic being processed by 
-the switch. Therefore, integrating new versions of software 
components or units into the system using the traditional "edit- 
compile-link-load-run" approach is not desirable. 

Another problem associated with the replacement of software in a 
operating computer system, such as telecommunications switches, 
is the state transfer between processes within the old software 
to processes within the new software, and especially the 
synchronization thereof. A process uses or comprises resource 
objects, which are object types that handle information on a 
hardware resource or an internal data structure. In context of 
the present invention it shall be understood that state transfer 
is the transfer of the state of a resource object. The state for 
a resource object is characterized by being allocated or 
deallocated. The state transfer between processes within the old 
software to the new software is essential to the users or 
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customers of the system, since the state of the resource objects 
can be used by and survive several transactions. The states of 
the processes change over time, which makes It impossible to In 
advance incorporate the states of these processes new 
5 version of software, and thus if it is going to survive it has to 
be transferred from the old to the new software during the 
replacement thereof. What is preferred is a method that provides 
IZ capability to modify or extend the software together with the 
£atT transfer between the old and the new version of software 
l0 w^le the system is in operation, and without any need for 
downtime • 

Attempts have been made to solve the problems associated with 
incorporating new software into operating computer systems. For 
some advanced on-line operational systems in use today 

15 "aTdo not operate In stand-alone or batch 

the problem of replacing old software in a manner that clearly 
Tt f«s from the method used with stand-alone or batch systems 

such systems still replace software manually, although 
transparently than in stand-alone systems, by requiring that 

20 ^olvld^users or user groups actively select whether or not to 
nrocess using the new or revised version of software. This option 

Software to be utilized by processes operating under their 
IndlvHua! user-Id. The option remains available to 
25 a fixed period of time, usually measured in weeks or 

which tL the software migrates up several levels in the 
concatenation structure after successfully operating at each 
prior level without any discrepancies, upon » 
Lvel of the concatenation, the software is declared oper 

reporting, approval, tracking software versions at 
35 Implementing approved changes. 
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new or modified software into a system in this fashion. It is 
largely a manual, labour intensive system that is complex and 
time consuming. It leaves the control over whether and in what 
cases the system will operate with certain new software to the 
users with no means of performing gradual, restricted, on-line 
use so that errors do not proliferate or immediately affect all 
ongoing operations. The method of controlling access to new or 
revised software is directly linked and limited to the individual 
user executing the software. 

Further, this method does not provide any means for transferring 
states from the old to the new version of software. Thus the 
state transfer from the old to the new software is lost, which of 
course could affect the users in a negative way. 

Other attempts to solve at least some of the problems associated 
with updating software in operational computer systems have been 
mad e. For example, in U.S. Application serial No. 07/907,294 to 
Telefonaktiebolaget L M Ericsson, there is disclosed a -^hod^for 
replacing software in an operating computer system. With this 
JLd it is possible to test and change software during actual 
operation of the telecommunications switch without disrupting 
ongoing telecommunications traffic through the system. This 
meLd, however, is not directed towards transferring states from 
the old to the new version of software. Even if this method 
recogni.es the need for such a state transfer it does not 
describe any means for synchronizing the data transfer from the 
old to the new software. 

Therefore it would be highly useful within In the telecommunica- 
ITZ Zl^ to he able to test and chance software, including 
state transfer of processes fro. the old to the new software, 
dX Tc^al operation of the telecommunications switch without 
disrupting ongoing traffic through the system. The present 
invention provides such a method. 

SUMMARY OF THE IMVEOTION telecom- 
The dynamic behaviour of computing systems such as SPC teleco 
munitions switching systems can essentially be described as a 
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-erles of parallel, relatively independent transactions (also 
birred to a -threads" or "chain of events") wherein every 
"Action consists of a number of related activities. A 
«^:"ion typically performs a Job that is visible and func- 
«^lv useful to the external user of the system. In a 
^o^unlcatlons switching system a typical transaction may he 

a call* 

M4ware replacement using the smooth change techniques 
^a" t^fer in accords with the present mention uses 

Sr^lon orients 'ZTJ^.I 



10 "^TT^Z new software versions at the same time. A 
storing botn oia ro a n ew version is accom- 

smooth change which transfers state* to ne» „ 

pushed hy allowing ongoing TransactioM 
„n to completion using the old software vers „ a£iic -, 
«. w=a after the software change has begun, i.e. . new trarr 

software ^ ^ ^ s ion o£ software 

— rr^ro^^^—i r:^: 

20 the old software. By means ^ states of the 

^ TZL^S Z ota software on an "as needed basis", 
^y^e ^ owner of the processes containing the 

ZZZ ~ ^- — the testin9 of the new ~"" are 

25 proceeds without any disturbances. 

v_, ^ smooth software change 

^^r«rf S er" present Invention include 
techniques with state xrans system 

, user disturbance and a high xevej. 

minimal or no user oj.st.im. n-rasent invention 

inability. ~r p £r<r^^ - 

30 include the facts that. U) system during a 

, hv an individual user of the sysxe» 

experienced by an inu software version 

^. « n call) because one and only one so^w 

„ old or the o new software by an 
since both software versions are used » parall 
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change; and (3) no states of the processes within the old 
software are lost because of the controlled state transfer 
between the old and the new versions of software. 

The states of the processes which have to be treated and 
5 transferred by the system can in this context be separated into 
two different classes: (1) dynamic processes which are created 
and used during a transaction and which are deleted after the 
transaction is completed; and (2) static processes which are used 
by and survives several transactions, for example in telecom 
10 systems, processes containing states about subscriber numbers 
connected to the system or short numbers used by certain sub- 
scribers. 

A crucial problem associated with online software replacement 
where minimal disturbance is required is that the state of the 

IS old software version has to be transferred to the new software 
version. Since both the old and the new software are operating 
parallel during the software change there clearly is no need for 
transferring dynamic processes, i.e. the process will be 
completed in the software version in which it was started. 

20 However, to be able to control in which version of the software, 
for example a new call, will be executed a selection point has to 
be provided to direct the traffic to the appropriate version of 
software . 

The present invention provides a mechanism to identify which 
25 software version is to be used during system upgrade. Besides 
normal traffic test traffic also has to be identified at the 
selection point and then be directed to the new version of 
software which has to be tested before it executes normal (live) 
traffic. 



<3 i~- : -r - V«- • .ff. 
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In another aspect, the method of the present invention also 
provides means to synchronize the state transfer of static 
processes within the old to the new version of software. The 
synchronization of state transfer between processes executing in 
the old and the new software according to the present invention 
35 comprises the following operations. 
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PrepareShutdown is the first operation on a static Pr°«ss 
declared in old software, i.e. the software to be replaced due to 
system upgrade. This operation prepares the application for a 
^hcoJng termination of the software to he replaced After 
receiving the PrepareShutdown signal the static process in^the 
oIT software publishes or activates an application specific 
interface for the transfer of resource objets (states). A 
^robject is an object type whose main purpose is to handle 
Illation on a hardware resource or an internal data 
^e with the transfer of a resource object the state of such 
information is transferred. 

After completion of this first operation the static process for 
Application within the new software is started and the new 
static Process is called with test traffic and gets necessary 
resource's from the old static process through the 
state transfer owned by the old static process. If the test 
traffic runs without disturbances on the new software normal 
«axflc will be executed by the new version of software, but the 
^rerface for state transfer is still owned by the old static 
process * 

Xf normal traffic also proceeds wit.out any 

elnnal applied to the static process wxthin the new 
Takeover signal is appxxea to will get: » the 

^. T=>T _ 0 w±tn tnis operation the new software win g 
con«r 0 f a£ refining resources from the old static process 
^ l ^.=e for state transfer owned by the old static 

process . 
shutdown . 

*t last the operation CommitTakeover is applied to the new 
"rsT o^of-are. T he new static proems ^inform, . that the 
new software is committed. Processes that are depe 
software system parts are terminated. 
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If the new software does not function properly the upgrading 
procedure may be reversed. If the reversion is made before the 
operation Takeover it is possible to carry out this reversion 
without any disturbances for the users. The reversion is carried 
5 out by applying the operation CommitTakeover to the old version 
of software instead of the new version of software. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a better understanding of the present invention and further 
objects and advantages thereof, reference can now be made to the 
10 following description, taken in conjunction with the accompanying 
drawings in which: 

1 shows a general telecommunications system; 

2 shows the system architecture in a general tele- 
communications system; 

FIG. 3 shows a block diagram illustrating an exemplary 

procedure for redirecting processing from an old 
software unit to a new software unit; 
FIG. 4 shows the synchronization during system upgrade 

without reversion according to the present inven- 

20 tion; 

FIG. 5 shows the synchronization during system upgrade 

with reversion according to the present inven- 
tion; 

FIG. 6 shows the synchronization and state transfer 

25 during system upgrade; 

FIG 7a-7n shows a practical example in which the smooth 

system upgrade method is applied on a resource 

server. 
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FIG. 
FIG. 
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PREFERRED EMBODIMENT 

The method according the present invention for replacement of old 
with new software, including state transfer, could, by way of an 
example be used in a SPC telecommunications exchange system, 
hereinafter referred to as switch. A general telecommunication 
system, including a switch 2, distributed processors 4, applica- 
tion software 6, data bases 8 and telephones 10 is depicted xn 
figure 1. The switch 2 is connected to one or more processors 4. 
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Tha cesser. 4 are also connected to application software 6. 
and to databases 8. as Known In the art. 

to fully understand how the method according the present 
Invent could he applied in such a syste. t- system architec- 
ture, shown i figure 2. will now be described. 

The most basic element in .his ^^^J^Tl^Z 
" ^ TrTng ^ZTJ^ZTZ^. ~ ' 

— ' - 1^ btthe Itod Of the present 

pro=.a^ T -ch a-C + ^is ^ ^ ^ in 

invention. The System upgr en titled "System for 

U.S. Application serial No. 07/907 .29. ^ex- 
changing software during computer operation to Tele 

i M Ericsson, hereby incorporated as reference _ 
aget L M Ericsso , appli cation software, which in this 

the operating sy^- l^e PP^ a part ^n to all 

example is ^edj^n two P #? slgMlling which is a 

software applications ( ^»' telecommunications systems, 

standard used for communication in tel ~ such ^ ISDN, 

and the specific software for each application. 

POTS, GSM, VLL etc. 

T he software « Is -^^^ ~ 
example in the above mentioned " leco context of the 

application software su^as ^-J^ ^ . sol tware 

m way « ±. ""^^J^. on old version of 

traffic while the normal traffic runs ^ new 

a fault occurs which can be associates 
software. If a fault occ reversed and the new software will 

software, the upgrade wxll be reversed a initiated by 

be removed. Reversion ^ ^^Tl ^ software, 
internally detected anomalies within the system upg 
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Fault management can force a reversion and the maintenance 
engineer is also given the possibility to break an upgrade and 
-thereby reversion. 

As mentioned above it is typical to replace only part of the 
software at a time. The software to be replaced is referred to as 
a change unit. In figure 3 there is shown an unchanged software 
unit 20 coupled through an addressing mechanism 22, called a 
direction point, to an old change unit 12 and a new change unit 
14. unchanged interfaces 16 and 18 link the old change unit 12 
and the new change unit 14 to the addressing mechanism 22. Figure 
3 illustrates the case in which there is a change unit in both 
the old software version, i.e. there is an old change unit 12, 
and in the new version of software, i.e. there is a new change 
unit 14. The new change unit 14 is by definition chosen to have 
an interface 16 that is compatible with the existing interface 18 
to the unchanged software 20. This means that the unchanged 
software is able to cooperate with both the old and the new 
software version (change unit). 

This aspect of the present invention, i.e., providing for the 
dynamic direction or re-direction of transactions, is facilitated 
by the introduction and use of direction points. These direction 
points consist of the places in the distributed system at which 
transactions may be directed in a particular way. The addressing 
mechanism 22 as illustrated in figure 3 represents the implemen- 
tation of the direction points and the means by which the 
system's transactions are individually directed to either the new 
or old software version. These direction points are capable of 
operating in three different ways. First, they may be triggered 
by analysing the function name associated with the traffic being 
processed by the system. According to this method of operation, 
traffic can be directed to either a new or old software version 
of the particular function required to perform the necessary 
processing. Second, transactions can be directed to execute a new 
or old software version of a program based upon information 
supplied as a result of runtime linking of the software. 

Two different cases of synchronisation will now be described, one 
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without reversion, which implies a successful upgrade and one 
when reversion is initiated during the system upgrade. The first 
TZ without reversion is shown in figure 4 and the second case 
HZ reversion is shown in figure S. In the figures a process is 
^Lolically shown by a rectangle having cut away comers. A 
Jy own one or more resource objects. Examples of 
ZTZl object are time slots, voice prompting eoulpment. etc. . 

Flcure 4 shows the different phases of and the synchronization 
duSng a s^tem upgrade without reversion when an old version of 
software is replaced by a new version of software. 

^ , „ h „se 1 the old static processes within the old software 
^Lrw^PrepareShutd^ signal beforethe new software 

" *~1L£ r ol^rt-by^rsTflhaJTignal be 
process wi«an «eo^ termiMtlon ^ remov al and prepares 

ZTZ transfer « stated. The old static process P«"--^ 
for the defined Interface for transferring the 

:"«Tre^ With publication is meant defining the 

communicates with other ^^^ITZ 
be called by the static process within the new ver 
may later be caxxea »y t Tne old static 

of software, for allocating resource objects. The 

= m « v also inform neighbouring processes, for example a 
Tor process about a forthcoming termination so that 
distributor P^ S ; reQunaant alternatives, according to 
routing can be done towards rea 907,294. 
the above mentioned U.S. Application serial No. 07/ ^ 
the aoo raffle will be handled as usual by the old 

During phase 1 all rraxii „„™ to an end when the 

version of software. This first phase comes to an 

new software has been loaded. 



i the static processes within the new software are 

in phase 2 the from s tart. Instead the 
started in a state dif ^ indica tes that 

static processes have to be * ^ and new s tatic 



s ^ic ^^J-J^Ts'tates between the old and new static 
there will be a transre xmmGtivml y the new version of 

processes within the old respeC * ±Ve J receives test 

software. During this phase the new ~~ the executi on 

traffic and subsequently normal <«~> Tne synchro n- 

of test traffic proceeds without any dxsturbances . T yn 
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ization of state transfer during test traffic will be described 
in greater detail in conjunction with figure 6, which describes 
state transfer during system upgrade. During this second phase 
normal traffic will first be handled by the old version of 
software, simultaneously with the test traffic handled by the new 
version of software. Thereafter all "new" traffic initiated after 
the test traffic has come to an end will be handled by the new 
software. The "old" traffic, i.e. the normal traffic prior to the 
ending of the test traffic, will be handled by the old version of 
software until it terminates. 

Since this example describes the system upgrade without reversion 
the test traffic and also the normal traffic executed thereafter 
proceeds without any disturbances. Therefore, in phase 3 the 
static processes within the new software are ordered to claim all 
resource objects of the static processes within the old software 
with a Takeover signal. This is the first operation introduced by 
the System Upgrade function on static processes declared in the 
new software. The application defined interface published or 
activated for state transfer is called by this new static process 
for transferring the control of resource objects and taking over 
all resource objects. During this third phase almost all traffic 
will be handled by the new software, except for the remaining old 
traffic handled by the old software. 

in phase 4 the old processes are ordered to remove all services, 
i e there are no more resource objects available to the old 
processes, with a CommitShutdown signal. There are two different 
criteria which could be used regarding the time when this 
CommitShutdown signal should be applied to the old processes. 
Firstly, this signal can be applied to the old processes when all 
of the old traffic handled by the old software has terminated. 
This ensures that no ongoing traffic will be disturb during 
system upgrade, since the services of the old software not will 
be removed until there is no more traffic to handle. Secondly, 
this signal can be applied to the old processes after a certain 
time has elapsed starting from the time when system upgrade is 
initiated. This will often give a much faster upgrading pro- 
cedure but also a risk of loosing some traffic (calls). When the 
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services have been removed the interface used for transfer of 
resource objects is withdrawn. After the CommitShutdown signal 
has been given all traffic will be handled by the new version of 
software . 

Thereafter. In phase 5. the old software Is blocked and removed 
„a in phase 6 the new process now Is the sole owner of the 
resource objects previously claimed from the old process. This is 
indicated by the commltrakeover signal to the new process. This 
signal is sent when the System upgrade function is committed and 
the static process will survive the upgrade. 

Ploure 5 shows the different phases of and the synchronization 
during a system upgrade with reversion when an old 
software is replaced by a new version of sof^are. The main 
difference of this case compared with that of figure * Is the 
receiver of the CommltTakeover signal. In this case the static 
Process executing in old software is the receiver and the owner 
process execu "3 .-version could be initiated either by 

of the resource objects. Reversion o« ™t 
the operation and maintenance technician or be carried out 

automatical ly . 

The reversion during system upgrade can be carried out at any 
time prior to the CommitShutdown signal, which is applied to the 
oiTstatlc Process as described above in conjunction with figure 
: Depending on in which phase the upgrading procedure ^s 
rev~»d thf result will differ. Referring to figure 5. two 
different cases of reversion will be described. 

t„ the first case, shown with an arrow co-mitTakeover 1. 

in the first • , . _ before the new static 

reversion is carried out in phase 2. i.e. before 
Locess receives the Takeover signal. During phase 2 first test 
.process receive „ ffic Mlll be handled by the new static 

traffic = and ^ ftic p ^ >a . prob lems will 

Tin dtV to the new" software reversion wiH be initiated by 
" lying the CommitTakeover signal ^^^ZZ, 
either automatically or by the upgrading i engineer. Si ^ 

static processes at this instance ^ ^ . ^ be 

resource objects no states of the old static p 
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lost due to reversion. The only thing that will happen is that 
the test traffic will be halted. The time during test traffic is 
the most common and also the most suitable to carry out rever- 
sion, since the users not in any way are affected by it. 
Reversion can also take place somewhat later in phase 2, i.e. at 
the time when the new software starts to execute normal traffic. 
If reversion is carried out during this time, still no states of 
the old static processes will be lost due to reversion. If there 
are severe problems with the new software there could be a 
problem in executing the ongoing normal traffic, but the new 
software will try to handle the normal traffic until it termin- 
ates. All normal traffic beginning after reversion, i.e. after 
the signal CommitTakeover has been applied to the old static 
processes, will be handled by the old software. 

in the second case, shown with an arrow CommitTakeover 2, 
reversion will be carried out after the signal Takeover has been 
applied to the new static processes, i.e. in phase 4. After the 
Takeover signal the new software, as described above, has taken 
control over all resource objects. A reversion, by applying the 
signal CommitTakeover to the old static processes, is possible 
but the states in the new static processes that have been changed 
during the time between the Takeover signal and the CommitTake- 
over signal will be lost. 

Reversion could also be done after the signal CommitShutdown has 
been applied to the old static processes, but all states will be 
lost, since the old software has to be initially started. 

Referring to figure 6, the synchronization of state transfer 
during system upgrade will be described. The state transfer 
interface, which is activated or published during phase 1 
described above, must be specified by the application to make it 
possible for the new static processes to coordinate and transfer 
the control of resource objects from the old processes. In figure 
6 and the description below the following generic operations 
within that interface will be used. 

GetResource, which operation transfers the control of a specific 
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resource object from an old static process to a new. This 
Ration is called when the new static process needs a specific 
resource object in control of the old static process. 

GetAnyResouxce, which operation transfers the control of a any 
resource object from an old static process to a new This 
^on is called when the new static process needs any 
resource object in control of the old static process. 

Ge^AilResources, which operation transfers the control of ^state 
^ „ * or all the remaining resource objects in the old 
^ t static Passes. This — ««- - 
ZT J °"t after that the new static processes have 

received the signal Takeover. 

The synchronization and state transfer during system 

2 r described cXoser in conjunction with figure 6. in which 

the upgrading procedure is divided in 8 phases. 

^ ore the upgrading p^ure start s tra ffic ^ — ^ ^ 
the old software. In phase ± rae 

Then in phase 2 the staxic P „^. iva -ted or published in 

new software is started. The port name activated or pub 
*his phase is the same as for the old software. 

phase 3. The test tr onera tion and maintenance 



•live" traffic preformed by the operation 



affic preioi»»» -j. - rp will 

^ineer. ^ing the test ^^£^7^ 
~r-7Z£T£Z- --cT^es get the necessary 

v zzz;i%™:~ the ol d static T ° :z: «-?^:~z 

resource ^^J^^^Z^^' — 

the new static processes have access to 

are still owned by the old static processes. 
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If the test traffic period proceeds without any disturbances the 
new static processes will be called with normal traffic, phase 4, 
and get necessary resource objects from the old static processes 
by either the operation GetResource or GetAnyResource through the 
interface for state transfer. During this period when new traffic 
is being handled by the new software the state of the resource 
objects that have been claimed by the new static processes, but 
still are owned by the old static processes, could change. This 
change is transferred back to the old static processes, since 
they are the owners of the resource objects. If this is not done 
this updated state information would be lost if a reversion 
becomes necessary. After this phase reversion without the risk of 
loosing state information is not longer possible. 

in phase 5 the new static processes are called with the System 
Upgrade function Takeover, which in turn activates the operation 
GetAllResources. The new static processes will now have the 
control of all the resource objects from the old static pro- 
cesses, in phase 6 the old static processes are called with the 
operation CommitShutdown and the application removes the 
interface activated or published in phase 1. Thereafter, in phase 
7 the old static processes will be terminated by the System 
Upgrade function. In the last phase 8 the new static processes 
are informed by System Upgrade that the new software are 
committed. Process dependent on old software system parts will be 
terminated . 

Below a practical example were the smooth system upgrade method 
is applied on a resource server will be described in conjunction 
with figures 7a-7n. A resource server is a static process which 
controls allocation and deallocations of pool resources. Pool 
resources are those resource objects which are mutually equival- 
ent i.e all resource objects within a pool are interchangeable, 
for' example DTMF-receivers , channels in a route or echo 
cancellers. In figure 7 an R will designate an object ^^ nt ' 
ing a pool resource. If the resource is idle it has a light 
background, as in the left hand side of figure 7a if the 
resource is allocated it is shaded, as in the right hand side of 
figure 7a and a resource not in control of the resource server is 
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drawn with dashed lines as in the right hand part of figure 7c. 

Before activating System Upgrade allocating and deallocating 
resources is performed in the normal way, figure 7a. If a 
requested resource is impossible to allocate the requesting 
process is informed about the lack of resources. This behavxour 
L unchanged even if there is an ongoing System Upgrade and the 
allocation is done through the interface for state transfer. 

The smooth System Upgrade method applied on the -source server 
will be described in correspondence to the 8 phases described in 
conjunction with figure 6. 

as shown in figure 7b the application is informed about a 
tarnation due to Svste* upgrade. The resource server publishes 
^interface for state transfer after receiving the signal 
^pareShutdown. as described above. Thereafter, as shown in 
floure 7C a new resource server is started in phase 2. The 
resources in the new resource server are as shown in figure 7c 
Resources not in control by the resource server. The old resource 
server still executes calls for allocating end deallocating 
resources as usual. 

in ohase 3 test traffic is routed against the new resource 
server whl'le normal traffic is routed against the old resource 
server' as shown in figure 7d. The control of a resource needed 

I- resource server is fetched via the 
transfer by the operation £ a re 

resources requested by the test traffic in fxg 
allocated in the new resource server. 

After tne test traffic has successfully been handled by the new 
^ After the test m _ f£lc will be directed against the new 

resource server normal traffic will con1:r ol of a 

resource server in phase 4, shown x figure 

resource is fetched when needed vxa the are two 

- r witn the operation GetAnyResource . There are 
transfer with the ^ ope resource is allocated and deal- 

possibilities xn phase 4. The resou fiau res 7g and 7h. 

located from the new resource server, shown „ ^ igures g 
The resource in the lower right comer xs allocated xn fxg 
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and returned in figure 7h. The other case is if the resource is 
allocated earlier in phase 3 with the old resource server and 
then deallocated in the new resource server. In this case the new 
resource server requests control of this specific resource 
through the interface for state transfer with the operation 
Get Resource, which is shown i figure 7i. The resource in the 
upper left corner is reserved in phase 1, figure 7b, in the old 
resource server and returned to the new resource server in phase 
4. The control of the resource is requested via the interface for 
state transfer with the operation GetResource. 

In phase 5, figures 7j and 7k, the control of all remaining 
resources are fetched via the interface for state transfer. The 
new resource server is called by the System Upgrade function with 
the operation Takeover and the remaining resources are fetched 
via the interface for state transfer with the operation GetAll- 
Resources, figure 7 j . After the GetAllResources operation the new 
resource server is in control of all the resources, which is 
shown i figure 7k with the transfer of the resource in the lower 
left corner to the new resource server. 

in phase 6, shown i figure 71, the old resource server is called 
from System Upgrade with the operation CommitShutdown, as 
previously described in conjunction with figure 6. In phase 7, 
shown in figure 7m, the old resource server is terminated by the 
System Upgrade function. In the final phase 8 the dynamic process 
dependent on the old software system parts are terminated by the 
System Upgrade function CommitTakeover. 

It is thus believed that the method of the present invention will 
be apparent from the foregoing description. While the method 
shown and described has been characterized as being preferred, it 
will be readily apparent that various changes and modifications 
can be made therein without departing from the spirit and the 
scope of the invention as defined in the following claims. 
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CLAIMS 



X. Method of synchronization allowing state transfer of 
resource objects from an old static process declared In an old 
software version to a new static process declared In a new 
sof ^Z version during the replacement of the old with the new 
version of software and without disturbing the ongoing actlv- 
4Mes comprising "Che steps of 

prying tne old static process within the old software for 
a forcing shutdown, activating it for the state «an=f e r . 

preparing the new static process within the new sof tware to 
ta*e ^transferring all resource objects in the old static 

— =r«£ z rrta^rto - — - 

.hat the new static process is the sole owner of all the resource 
objects previously claimed from the old static process. 

* Method of synchronization according to claim 1. wherein the 
s^p ^pariT-e old static process for shutdown comprises 
riveting or publishing an interface for state transfer. 

3. Method of synchronization according to X 

step of preparing the new ^fTe ^r state 

ailocation and deallocation, through th ' ss 
transfer, of certain resource objects in ^^J^ ^ MW 
needed by the new static process during a period when 
static process receives test data. 

4 . Method of synchronization according to claim 3. 
response to a successful, processing of test data .J* 
software all resource objects are transferred from the 
new static process. 

s . Method of synchronization according to claim 
response to an unsuccessful processing of test 
sofLare is removed and the resource objects remain in 

the old software. 
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6. Method of replacing a old version of software with a new 
version of software in a telecommunications system, without 
disturbing the ongoing activities, comprising the steps of 

preparing the old static process within the old software for 
a forthcoming shutdown, activating it for the state transfer, 

loading the new software into said telecommunications 
system, while the old software processes normal traffic, 

testing the new software with test traffic in parallel with 
the processing of normal traffic on the old software, 

processing new normal traffic with the new software in 
parallel with the processing of old normal traffic with the old 
software, 

preparing the new static process within the new software to 
take over, transferring all resource objects in the old static 
process to the new static process, 

ordering the old static process to remove all services, 
terminating the old static process, and 

committing the new static process to take over, indicating 
that the new static process is the sole owner of all the resource 
objects previously claimed from the old static process. 

7. The method according to claim 6, wherein the step of 
preparing the old static process for shutdown comprises activat- 
ing or publishing an interface for state transfer. 

8. The method according to claim 6 or 7, wherein the step of 
testing the new software, comprises allocation and deallocation, 
through the interface for state transfer, of certain resource 
objects in the old static process needed by the new static 
process during the period of test traffic. 

- 9 Method according to claim 8, wherein in response to a 
successful processing of test traffic by the new software all 
resource objects are transferred from the old to the new statxc 
process ♦ 
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10. Method according to claim 
unsuccessful processing of test 
removed and the resource objects 
old software. 
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data the new software will be 
will remain in control of the 
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